A storage system is a processing system adapted to store and retrieve information/data on storage devices (such as disks). The storage system includes a storage operating system that implements a file system to organize logically the information as a hierarchical structure of directories and files on the storage devices. Each file may comprise a set of data blocks, whereas each directory may be implemented as a specially-formatted file in which information about other files and directories are stored.
The storage operating system generally refers to the computer-executable code operable on a storage system that manages data access and access requests (read or write requests requiring input/output operations) and may implement file system semantics in implementations involving storage systems. In this sense, the Data ONTAP® storage operating system, available from NetApp, Inc. of Sunnyvale, Calif., which implements a Write Anywhere File Layout (WAFL®) file system, is an example of such a storage operating system implemented as a microkernel within an overall protocol stack and associated storage. The storage operating system may also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.
A storage system is typically implemented as one or more storage volumes that comprise physical storage devices, defining an overall logical arrangement of storage space. Available storage system implementations may serve a large number of discrete volumes. A storage volume is “loaded” in the storage system by copying the logical organization of the volume's files, data, and directories, into the storage system's memory. Once a volume has been loaded in memory, the volume may be “mounted” by one or more users, applications, devices, and the like, that are permitted to access its contents and navigate its namespace.
A storage system may be configured to allow server systems to access its contents, for example, to read or write data to the storage system. A server system may execute an application that “connects” to the storage system over a computer network, such as a shared LAN (local area network), WAN (wide area network), or VPN (virtual private network) implemented over a public network such as the Internet. The application executing on the server system may send an access request (read or write request) to the storage system for accessing particular data stored on the storage system.
In compliance environments, a mechanism may be used to commit files to “immutable” status on a rewritable storage media after the files have been written and have not been modified for a predetermined period of time (referred to as the “auto-commit time period”). A compliance environment may comprise a storage system configured to meet a set of legal or corporate requirements (e.g., a requirement that records are to be kept for a certain period of time or are auto-committed to immutable status after the predetermined period of time). Immutable status may comprise a storage setting that provides the file with all protections of a file that was written on a non-rewritable media. In other words, immutable status may indicate that the file is irreversibly read only and can not be changed/modified (where attributes of the file may or may not be modifiable). Placing files in immutable status is useful, for example, in financial environments where documents may be required (by legal or corporate requirements) to be made unchangeable and secure for auditing.
There are various ways to commit files to immutable status on rewritable storage systems. Data ONTAP® is an example of a system that may be configured to commit files to immutable status. Conventional mechanisms to commit files to immutable status on such rewritable platforms include usage of APIs (Application Program Interfaces), Protocols like NFS/CIFS (network file system/common Internet file system) and auto-commit. In one example of a conventional mechanism, an administrator may use an API to manually designate individual files to be made immutable. Those designated files are then made immutable immediately by the storage system. In another example of a conventional mechanism, “auto-commit” is a feature exported by Data ONTAP®, where administrators may setup an auto-commit time period on the storage system. The administrator may apply the auto-commit feature to a particular set of files on the storage system (e.g., all files within a volume, all files within a directory, etc.). If the files are not modified within the auto-commit time period, they are automatically committed to WORM (Write Once Read Many) status (i.e., immutable status) by the storage system itself without any user intervention. This feature provides a way for customers to commit automatically their data to immutable status in a regulatory compliance environment without making any changes to their application or deployment environment.
One challenge in implementing the auto-commit feature is determining when the files have met their auto-commit requirement, in other words, when the “auto-commit time period” has elapsed since the file was last modified. Data ONTAP® typically implements this auto-commit feature using system scanners. These scanners are threads or processes in the storage system that run in the background continuously, scanning each inode of the entire file system repeatedly to discover files that have met their auto-commit requirement. File system inodes are data structures that contain information about files that are created when a file system creates the files. Each file has an associated inode that is identified by an inode number (i-number) in the file system. These inodes provide important information on files, such as user and group ownership, access mode (read, write, execute permissions) and type. After scanning inodes and discovering files that have met their auto-commit requirement, scanners commit these files to immutable status.
Use of the system scanners in implementing the auto-commit feature, however, is time and resource intensive since the system scanners constantly process files. As such, there is a need for an improved method for implementing the auto-commit feature that is not as time and resource intensive.